rootfs: only set mode= for tmpfs mount if target already existed #4973
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cyphar
added
backport/1.2-todo
cyphar
force-pushed
the
tmpfs-mode
branch
3 times, most recently
from
0a6577f to
8d0921c
Compare
lifubang
approved these changes
Nov 8, 2025
Member
Author
|
This patch seems to trigger errors from criu-dev more consistently than the flakes we've been seeing in the past few weeks... Odd... |
Member
In fact, I suggest to remove the |
Member
Author
|
I saw that, but the fact it fails more consistently with this change seems to imply it's not the same flake. Normally retrying the job succeeds after one (or maybe two) attempts, but this PR has failed >10 times in a row with multiple tests failing. Also note that criu-dev will eventually be released and we will have to deal with the same issue in the future, so I don't really see the benefit of just removing the CI job. @kolyshkin has spent some time debugging the issue in checkpoint-restore/criu#2781 and it appears that we found an issue in CRIU thanks to this testing. |
Member
|
I think we already have a CI job that tests the latest stable version of CRIU, so testing the project in development mode doesn’t really make sense—at least in my opinion. I could be wrong, though! |
Contributor
Member
Author
|
@rst0git The error I saw yesterday was different and it was CRIU related, there is a separate flake I need to work around. I'll get you a copy of the logs on Monday. |
Member
|
Member
Author
|
And of course now it passes when I ran it again... |
This was always the intended behaviour but commit 72fbb34 ("rootfs: switch to fd-based handling of mountpoint targets") regressed it when adding a mechanism to create a file handle to the target if it didn't already exist (causing the later stat to always succeed). A lot of people depend on this functionality, so add some tests to make sure we don't break it in the future. Fixes: 72fbb34 ("rootfs: switch to fd-based handling of mountpoint targets") Signed-off-by: Aleksa Sarai <[email protected]>
Member
Author
|
This is ready to review by the way, @opencontainers/runc-maintainers. |
kolyshkin
added
backport/1.2-done
edmorley
added a commit
to heroku/heroku-buildpack-python
that referenced
this pull request
Nov 14, 2025
The Python classic repo's CI just started failing in the container-test job with: `mkdir: cannot create directory '/app/.heroku': Permission denied` eg: https://github.com/heroku/heroku-buildpack-python/actions/runs/19368179568/job/55418539741 After updating Docker locally, I was able to reproduce the error, and have found it's due to the recent runc 1.33 release: https://github.com/opencontainers/runc/releases/tag/v1.3.3 This runc release includes a number of security fixes - however, one of which has a regression: opencontainers/runc#4971 There is a fix for this upstream: opencontainers/runc#4973 ...but it's not released yet. However, we can work around the issue by explicitly setting the previous tmpfs permissions using `:mode=1777`: https://docs.docker.com/engine/storage/tmpfs/#options-for---tmpfs GUS-W-20221627.
edmorley
added a commit
to heroku/heroku-buildpack-python
that referenced
this pull request
Nov 14, 2025
The Python classic repo's CI just started failing in the container-test job with: `mkdir: cannot create directory '/app/.heroku': Permission denied` eg: https://github.com/heroku/heroku-buildpack-python/actions/runs/19368179568/job/55418539741 After updating Docker locally, I was able to reproduce the error, and have found it's due to the recent runc 1.3.3 release: https://github.com/opencontainers/runc/releases/tag/v1.3.3 This runc release includes a number of security fixes - however, one of which has a regression: opencontainers/runc#4971 There is a fix for this upstream: opencontainers/runc#4973 ...but it's not released yet. However, we can work around the issue by explicitly setting the previous tmpfs permissions using `:mode=1777`: https://docs.docker.com/engine/storage/tmpfs/#options-for---tmpfs GUS-W-20221627.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This was always the intended behaviour but commit 72fbb34 ("rootfs:
switch to fd-based handling of mountpoint targets") regressed it when
adding a mechanism to create a file handle to the target if it didn't
already exist (causing the later stat to always succeed).
A lot of people depend on this functionality, so add some tests to make
sure we don't break it in the future.
Fixes #4971
Fixes: 72fbb34 ("rootfs: switch to fd-based handling of mountpoint targets")
Signed-off-by: Aleksa Sarai [email protected]